posted 03-01-2002 03:20 AM          

quote:

---

Originally posted by Maj: There's also no practical way I know of using bumpmapping with [lightmaps].

---

posted 03-01-2002 04:35 AM          

quote:

---

Originally posted by bushboy: I did a quick experiment - JL, I guess you were refering to the -samplesize switch in the light section of q3map ? I tried modifying it to 8, 32 & 64 (it defaults to 16), using the following -samplesize x - I got a number of strange errors in vlight, light -extra doesn't output errors, but it seems to make no difference to the lightmap that q3ase extracted, or any diffence ingame ?

---

Yes there is a big difference in game. small objacts can cast dramatic shadosw which are further enhanced in combination with radiosity. I have tried this on some small samples.
The important thing is: U must use the -samplesize x argument(i tried values from 1 - 12) in the bsp stage. It doesnt seem to have any effect when applied in the light stage.
[edit] maybe it helps to apply it both during bsp and light.... but the important thing is to use it during bsp for it to work

But even then there was a strange thing. It didnt create the high res shadows on one of my ground brushes, I think it might have been the first one I created I dont know. But the shadows were high res on all other brushes in the map - i have no clue why not on tis one though.

also, the high res light map did not have any impact on FPS as far as could tell, but like i said it was just a test room. But it does have a huge impact on compiling times as well as bsp size...

posted 03-01-2002 01:33 PM          

It's been an interesting challenge. Rewrote the basic lighting pipeline about 20 times, trying different algorithms, optimizations, etc. I'm pretty happy with how it's turned out. The pipeline is divided into logical segments: allocation, projection, determination (mapping), illumination, flooding, filtering, subsampling, diffuse calculation, compression, re-projection, and storage.

The modular nature now lets me experiment with one portion of the pipeline without disturbing the rest.

This weekend I was planning on holing up in my office and giving a go at writing a shadow-volume BSP generator. Each lightsource would have a unique SVBSP that would enable quick determination of light/dark for any arbitrary point in the world.

It should drop neatly into the illumination module without any significant rearchitecting of the rest of it.

Lightmaps are a good thing. Like Maj said, they're basically free at runtime. It will be a little while before realtime illumination for geometry as complex as Quake 3 approaches the quality of precomputed lighting.

For every leap forward in realism, something initially has to give. Take, for instance, Quake 1. It had nowhere near the character throughput that the original Doom engine allowed on the same hardware. It simply wasn't possible to render texturemapped triangle models as fast as 2d billboards.

But Moore's law marches on, and today we have Serious Sam with hundreds of baddies onscreen at any time, all rendered in fully-lit, texturemapped glory.

Unless the new Doom has some sort of static precomputed lighting in addition to the realtime lightsources, there is simply no way that the number of lightsources in a Doom map could approach what you have in a typical Quake 3 map.

I'm sure there will be some vocal whiny backlash "why can't I make maps like Quake???" because of it. But--I'm probably going to get caught with my pants down on this one--the bar will be back up again in a year or two.

For those of you who are interested, here is a half-decent paper on shadow volume BSPs.

y

P.S.
Q3Map can import/export lightmaps now, as well as filter them:

-light

-light -super 2 (-extra)

-light -super 2 -filter (-extrawide)

Edit: Forgot to mention, -filter is free and can be used with or without supersampling.

posted 07-31-2002 02:33 PM          

quote:

---

Originally posted by WangButter: ydnar has kinda singlehandedly made the whole lightmap editing thing obsolete.

---